November, 1995: Although we are now into the v5.1 world of the DT, this document is still being included because some of its pieces continue to be relevant and continue to be referred to in other documents.
This document describes the HTML (client) and HTTP (server) issues relating to the operation of this, version 5.0, Developer Toolbox CD. The areas discussed are:
I. Environments in which v5.0 will operate:
II. The benefits of having an HTTP server running in your local machine's environment.
III. Known Bugs and Limitations of this specific netscape 1.0 Browser:
IV. Defining netscape's "SOCKS Host:" and "Port:" fields to match your environment's firewall
V. World Wide Web.
IntroductionWelcome to the "first cut" of next step in the evolution of the Developer Toolbox. This Toolbox is the first to begin fully employing the power afforded with Hyper Text Markup Language (HTML) functionality, where "hyper-links" or "linked-text" (as well as other linked-data, i.e. images, sound files, movie clips, etc.) provides any document file with an enormously useful "cross-reference" capability, which in turn gives documents a multi-dimensional depth and texture not possible with paper and books.
All HTML-written documents are interpreted by and presented inside the sort of client "browser" you are now reading this document with. For all such documents to be "served up" with 100% operability, one must have an Hyper Text Transfer Protocol (HTTP) server running and accessible on the network one's machine is on. With an HTTP server running, one can make requests through the client browser, which are then processed and responded to on the server side of this paradigm. A Web Terminology Glossary is available for those unfamiliar with HTML and HTTP terminology.
The janitor is very pleased to have on-CD copy of all SGI WebFORCE(TM) technical information pages -- as well as Irix 5.3 WebFORCE(TM) product descriptions and information regarding local inst images. With respect to WebFORCE(TM) technical information, the pertinent topic areas are:
The following two sections describe how to "hook-up" the contents of the v5.0 Toolbox CD to an HTTP server if one has access to such a server in one's own local network environment. For those who just "stepped into this document" at this location, be sure to see the overview information at the top to help you understand all the HTML and HTTP issues relating to the operation of this, v5.0 Toolbox. The following two sections,
are predicated on the fact that an HTTP server exists and is accessible. If this is not the case, you can obtain NCSA's public domain HTTP server, if you have ftp Internet access. Otherwise you need to know about the 3 types of links which won't work through this interface as it is currently configured on the v5.0 CD itself.This method, of creating a symlink from /CDROM to /Your/DocumentRoot/toolbox, is for those people who:
Then, you should be able to call up the URL like so:
http://yourServerName/toolbox/
and, underneath Add a New CGI Directory, put in (in bold) the following:
Map URL prefix: /toolbox/www/cgi-bin To directory: /AbsolutePath/to/DocRoot/toolbox/www/cgi-binAfter successfully adding this, restart your server and yer all set.
ScriptAlias /toolbox/www/cgi-bin/ /usr/local/www/toolbox/www/cgi-bin/
Running /etc/killall httpd followed by a something like,
will now add /toolbox/www/cgi-bin/ to your httpd server's group of cgi-bin definitions. You can have up to 20 such concurrently-defined definitions, provided no first argument following "ScriptAlias" is the same as any other.
After adding this, restart your server and yer all set.
This method, of creating a copy of the contents of /CDROM that lives under /Your/DocumentRoot/toolbox, is for those people who:
The SGI inst images not needed to be copied reside in two sudirectories,
IF you have 452MB free on your disk, you could do the following:
rcp -pv -r /CDROM /Your/DocumentRoot/toolbox cd /Your/DocumentRoot/toolbox rm -rf dist searchtools/dist
mkdir /Your/DocumentRoot/toolbox cd /Your/DocumentRoot/toolbox rcp -pv -r [D-c]* do* [h-r]* sg* si* src [t-w]* . mkdir searchtools cd searchtools rcp -pv -r [D-O]* [g-t]* .
and, underneath Add a New CGI Directory, put in (in bold) the following:
Map URL prefix: /toolbox/www/cgi-bin To directory: /AbsolutePath/to/DocRoot/toolbox/www/cgi-binAfter successfully adding this, restart your server and yer all set.
ScriptAlias /toolbox/www/cgi-bin/ /usr/local/www/toolbox/www/cgi-bin/
Running /etc/killall httpd followed by a something like,
will now add /toolbox/www/cgi-bin/ to your httpd server's group of cgi-bin definitions. You can have up to 20 such concurrently-defined definitions, provided no first argument following "ScriptAlias" is the same as any other.
After adding this, restart your server and yer all set.
oksvr program, plus the osearch-cgi
and oretrieve-cgi scripts, the location of the index files
it needs to know about, while /usr/tmp/.DT_DocRootFile tells the
tar-cgi, tarDFList-cgi, and
tarsend-cgi scripts the location of your server's Document Root.
A document describing how to configure
the OasisIII Search Software--which includes the oksvr
program--provides all the information needed to configure the
CGI search mechanism including creating the contents of the
/usr/tmp/.DT_OksvrRoot file.
For the tar-cgi, tarDFList-cgi, and
tarsend-cgi scripts you will need to have
/usr/tmp/.DT_DocRootFile contain the location of your HTTP
server's document root. For example, let's say your Document Root
is /usr/local/www. In this case, the contents of
the your /usr/tmp/.DT_DocRootFile file should be (the entire
following line):
$DocumentRoot="/usr/local/www";
Once you've created this file with the perl variable $DocumentRoot
defined to be the string "/usr/local/www", the
tar*-cgi scripts will all function properly AFTER
YOU PERFORM ONE FINAL STEP:
cd
/your/doc/root
mkdir
tmp
chown 777 tmp
This is needed for the tar-cgi and
tarDFList-cgi scripts, as both of these scripts create
a temporary directory in DocumentRoot/tmp and put the
compressed tar file there before the user accesses it as a regular
URL to download it back to their own system.
THE ONE CAVEAT to the v5.0 CD's tar*-cgi scripts
is that unless they access the "where you just were" button at
the bottom of the "Successful Generation of Multiple -Files &|
-Directories Compressed Tar Image" form, the temporary directory
and it's accompanying compressed tar image will NOT be
removed. This is a regretable situation which the
janitor did not have time to address before the CD was
finished. Until the upgraded functionality is in implemented and
available you should create a cron job which runs nightly and removes
any directories that are older than 24 hours.
The following four sections present information relevant for environments where Internet Access may or may not exist:
-rwxr-xr-x 1 11113 729 50823 Feb 20 13:30 httpd_ascii_docs.tar.Z -rwxr-xr-x 1 11113 729 309775 Mar 1 18:35 httpd_decaxp.tar.Z -rwxr-xr-x 1 11113 729 1177671 Feb 20 13:29 httpd_docs.tar.Z -rwxr-xr-x 1 11113 729 437151 Feb 20 13:25 httpd_hp.tar.Z -rwxr-xr-x 1 11113 729 89045 Feb 20 13:30 httpd_postscript_docs.tar.Z -rwxr-xr-x 1 11113 729 329551 Feb 20 13:20 httpd_rs6000.tar.Z -rwxr-xr-x 1 11113 729 447290 Feb 20 13:33 httpd_sgi.tar.Z -rwxr-xr-x 1 11113 729 108663 Mar 9 11:51 httpd_solaris.tar.Z -rwxr-xr-x 1 11113 729 115211 Feb 20 13:00 httpd_source.tar.Z -rwxr-xr-x 1 11113 729 222311 Feb 20 13:00 httpd_sun4.tar.ZOne can also obtain precompiled server binaries if you have Web access.
Once you have successfully installed and configured your NCSA HTTP server, you can either
to create a 100%-functional HTML-ized v5.0 Toolbox.Keep in mind this HTTP server is equivalent to the X Window System server (XSGI(1)) on your SGI machine: both are network host programs which service requests made by client programs operating within the same network. Just as the X server processes requests made by client programs like the window manager, graphics applications, etc., so the HTTP server processes requests initiated by client browsers like netscape.
Even without an HTTP server running, there is a lot a web browser like netscape can do in a "standalone mode" when it is pointed at a [set of] HTML document[s]. First-and-foremost, a web-browser is an interpreter--it takes whatever HTML document file it is directed to read, interprets all the HTML elements in that file, and then displays the results of that interpretation. It is not possible to explain the benefits of running an HTTP server without describing a little bit about how HTML documents are accessed through a web browser--with or without the assistance of an HTTP server.
Running a web browser in "standalone mode" (i.e. without an HTTP server) is exactly what the v5.0 DT CD "toolbox" script (located in the top-of-tree) does: note the beginning of the last line where netscape is invoked:
netscape file:/CDROM/DT.html
The above argument to netscape is called a Uniform Resource Locator, or URL, and its syntax specification goes like this (taken from the local-to-the-DT-copy of the World Wide Web FAQ): "The first part of the URL, before the colon, specifies the access method. The part of the URL after the colon is interpreted specific to the access method. In general, two slashes after the colon indicate a machine name."
And, from the first paragraph of the local-to-the-DT-copy of A Beginner's Guide to URLs, we have another useful definition of what constitutes a URL:
Think of it as a networked extension of the standard filename concept: not only can you point to a file in a directory, but that file and that directory can exist on any machine on the network, can be served via any of several different methods, and might not even be something as simple as a file: URLs can also point to queries, documents stored deep within databases, the results of a finger or archie command, or whatever.Recall in the toolbox script, we are pointing netscape at a URL of type file (this URL-type is synonymous with ftp). While employing such file-type URLs is a fundamental necessity in applications where an HTTP server may not exist (just like the way it is being used in the toolbox script on this CD), such constraints limit the functionality of what else can also exist--and DOES on this Toolbox--in HTML documents.
The way the entire Toolbox's HTML files were re-crafted to work on this CD without an HTTP server running was to use the URL file scheme, and, in concert with this, to make all the links have relative rather than absolute paths. But, as we shall now see, there are many limitations to this methodology of accessing a collection of HTML documents via the URL file scheme.
The following is a explication of the different links on this Toolbox which require an HTTP server to process them. These links will fail on this Toolbox when they are accessed via a web browser using the file URL (as is the case with the toolbox script), which in effect is equivalent to saying, when they are accessed without the benefit of an HTTP server running to process all the requests that can be made through such a client-server interface.
Onboard the Toolbox there are links employing CGI which must have an http server running in order for the interface to be functional. These are the (These are live links--they won't work if yer running this browser via "netscape file:...") Search and Pheedbak links in the "navigator line" at the top of practially every Toolbox-specific html page (including the top of this page) on the Toolbox. If you select either of these links, the Unable to locate file window will again be barking at you. Both "Search" and "Pheedbak" links point to different HTML FORM documents.
For people who do not have access to HTTP server software, but do have ftp access to Internet, the public domain NCSA HTTP server software is available. For people who don't have an HTTP server running, and don't have access to the Internet, there are alternative methodologies to the functionality available through the 3 above-mentioned types of links described in the next section.
There are two distinct ways one can copy files off to one's own local disks. To identify where on the CD the given page is located, refer to the "Location" text widget line/box at the top of the netscape browser window (between the two lines of buttons). This line can be "edited," as well as being cut-and-paste:
rcp -pv /abs/path/to/current/dir/{filename1,filename2,...,filenameN} .
admittedly, the above "alternatives" are a pretty shitty interim way to "help" people hobble along. all this sort of tripe would be a non-sequitor if the janitor had succeeded in finding a way to include an HTTP server on the Toolbox so EVERYTHING would have simply worked from the very start for EVERYONE. chalk this up to more of the janitor's learning curve. just wait until v5.1 arrives--the janitor expects you will be very pleezed with the results!
The following discussion is written for both those people working in secure environments who will never be able to be connected, as well as those people working in environments where connecting to the Internet is a possibility. However, the last part of this discussion, Getting Connected to the Web will only be useful for people in the latter situation.
99.7 percent of the URLs in the Web Jumpdoors, FAQs, and www/www.html files consist of the http type. The www/httpd1.3docs subtree of documentation on the NCSA HTTP server also contain a number of http links. There are a few other http links scattered throughout the Toolbox. A few ftp URLs exist in the Web Jumpdoors, FAQs files as well as in the "contenders.html", "documents/OpenGL/index.html", "www/html/html.html", "www/www.html", "www/www_faq.html", and "src/exampleCode/opengl/GLUT/index.html" files.
Accessing the mailto URL will work, but, if you do not have an Internet connection that allows e-mail messages to be sent outside your site, then, this message will eventually come back to you marked "USER UNKNOWN".
If you do not have a direct connection to the Internet through some sort of socks or proxy server running on a firewall system(s), the first two of these three URL's will fail since they will not be able to contact/connect with the remote host the http and ftp URLs specify. If you attempt to access such an external URL on this Toolbox, you will see an Error notifier window pop up which barks about how the netscape client is:
Unable to locate hostGetting Connected to the Internet and the Web
The remaing three sections present issues surrounding the operation of the Irix 5.2 netscape program that exists in the top-of-tree directory of this, v5.0, Toolbox.
Another point to note: when you access a link to a compressed file like PostScript or showcase, what happens (when things work) is the file is first uncompressed, and a temporary copy of this uncompressed file is created on your local disk (usually in some place like /usr/tmp). The benefit of accessing the uncompressed file link is that no such temporary local copy of said file is created on your local disk. This is a benefit for those who suffer from chronic disk space shortages and can't afford to house [large] files--even just temporary ones--on their own disk(s). Obviously, where viewing a document across the Internet is concerned, there clearly are advantages to first bringing the file across in a compressed form, and then uncompressing it after it's "completed its trip". This was a large motivating factor in crafting the [Generate] a compressed tar image... buttons and accompanying CGI-script functionalities at the bottom of every directory's index.html file page.
While testing this CD on a standalone system not connected to a network and not running sendmail, we discovered a fatal bug relating the the mailto URL which causes netscape to dump core and crash. The sequence goes like this:
The following pull-down menu entries will fail, after a time-out of more than a minute, if you attempt to access them; once the timeout occurs one or two Error notifier windows will bark you about Warning: the following hosts are unknown:... and/or Unable to locate host
Two segments follow: the first contains words-of-advice from one of the webforce-software gauds inside SGI; the second is an excerpt from Netscape Communications Corporation's documentation regarding proxy software/servers.
The janitor was asking for information about the tricky buisness of correctly configuring your access to the internet if your local network environment is behind a firewall. The response included the following helpful advice:
One other thing you may have to worry about is if they have NIS or DNS configured and running, then they may need to have a properly configured /etc/resolv.conf file in order to resolve host names.A second point is when running socks, you may need a properly configured /etc/socks.conf so that accesses within the network don't use socks, while accesses outside the network do use socks. It also helps to cut down the number of internal sites looking like they came from the socks server.
The following excerpt is included from Netscape Communications Corporation's http://home.netscape.com/newsref/manual/docs/menus.html#C21 "Menu items" page discussing "Mail and Proxies (dialog in Preferences in Options)", to help clarify the issue of correctly defining one's "SOCKS Host:" and "Port:" fields inside the Mail and Proxies window of your Options->Preferences pull-down menu entry.
Ordinarily, the Netscape application does not require proxies to interact with the network services of external sources. However, in some network configurations the connection between the Netscape application and a remote server is blocked by a firewall. Firewalls protect information in internal computer networks from external access. In doing so, firewalls may limit Netscape's ability to exchange information with external sources.
To overcome this limitation, Netscape can interact with proxy software. A proxy server sits atop a firewall and acts as a conduit, providing a specific connection for each network service protocol. If you are running Netscape on an internal network from behind a firewall, you will need to ascertain from your system administrator the names and associated port numbers for the server running proxy software for each network service. Proxy software retains the ability to communicate with external sources, yet is trusted to communicate with the internal network.
A single computer may run multiple servers, each server connection identified with a port number. A proxy server, like an HTTP server or a FTP server, occupies a port. Typically, a connection uses standardized port numbers for each protocol (for example, HTTP = 80 and FTP = 21). However, unlike common server protocols, the proxy server has no default port. Netscape requires that for each proxy server you specify in a Proxy text field, you also specify its port number in the Port field.
Text fields for proxies and ports are offered for FTP (File Transfer Protocol), Gopher, HTTP (HyperText Transfer Protocol), Security (Secure Sockets Layer protocol), WAIS (Wide Area Information System), and SOCKS (firewall bypass software).
- Text in each Proxy field designates the host name of each protocol's proxy server. (Often, a single proxy server handles the three major protocols: HTTP, FTP, and Gopher.) This can also be a numeric IP address of the proxy server.
- A number in each adjacent Port field identifies the port number used by the proxy server.
The text field No Proxy for: lets you bypass the proxy server for one or more specified local domains. For example, if you specify:
HTTP Proxy: aserver.netscape.com Port: 8080
then all HTTP requests for the adomain, bdomain, and netscape.com host servers go from Netscape directly to the host (not using any proxy). All HTTP requests for other servers go from Netscape through the proxy server aserver on port 8080, then to the host. A proxy that runs on a host server outside a firewall cannot connect to server inside the firewall. To bypass the firewall's restriction, you must set the No Proxy for field to include any internal server you're using. If you use local hostnames without the domain name, you should list them the same way. Multiple hostnames are delimited by commas and the wildcard character (*) cannot be used.
No Proxy for: adomain,bdomain,netscape.com
See Also: "SOCKS support in the Netscape Navigator" at http://home.netscape.com/assist/support/client/tn/cross-platform/10021.html.
Netscape*visualID: BestHowever, doing this will cause numerous Xerror messages to be sent to the screen or console.
Netscape*preeditType: None
Copyright © 1995, Silicon Graphics, Inc.